Configuration Guide

You can run JBoss EAP as a standalone server to manage a single instance of JBoss EAP.

The server starts in a suspended state and does not accept requests until all required services start. After required services start, the server transitions into a normal running state and can start accepting requests.

This startup script uses the EAP_HOME/bin/standalone.conf file, or standalone.conf.bat for Windows Server, to set default preferences, such as JVM options. You can customize the settings in this file.

JBoss EAP uses the standalone.xml configuration file by default, but you can start it using a different one.

You can run JBoss EAP in a managed domain operating mode to manage several JBoss EAP instances using a single domain controller.

Servers start in a suspended state and do not accept requests until all required services start. After required services start, the servers transition into a normal running state and start accepting requests.

You must start the domain controller before the servers in any of the server groups in the domain.

This startup script uses the EAP_HOME/bin/domain.conf file, or domain.conf.bat for Windows Server, to set default preferences, such as JVM options. You can customize the settings in this file.

JBoss EAP uses the host.xml host configuration file by default, but you can start it using a different configuration file.

When setting up a managed domain, you must pass additional arguments into the startup script.

You can stop an interactive instance of a standalone server or a domain controller from the terminal where you started it.

You can connect to the management CLI to shut down a running instance of a standalone server or servers in a managed domain.

When running an instance of JBoss EAP on servers in a managed domain, you must specify the host name to shut down by using the --host argument with the shutdown command.

You can run a JBoss EAP instance in admin-only mode using a standalone server.

In a managed domain, if a domain controller is started in admin-only mode, it will not accept incoming connections from secondary host controllers. A host controller started in admin-only mode will not start servers.

JBoss EAP 8.0 provides a suspend mode that gracefully suspends server operations. This allows all active requests to complete normally, but will not accept any new requests. Once the server has been suspended, it can be shut down, returned back to a running state, or left in a suspended state to perform maintenance.

The server can be suspended and resumed using the management console or the management CLI.

Each example waits up to 60 seconds for requests to complete before suspending.

:resume

:resume

A server will be shut down gracefully if an appropriate timeout value is specified when stopping the server. Once the command is issued, the server will be suspended and will wait up to the specified timeout for all requests to finish before shutting down.

Use the following management CLI commands to shut down the server gracefully. Specify the timeout value, in seconds, for the server to wait for active requests to complete. The default is 0, which shuts down the server immediately. A value of -1 will cause the server to wait indefinitely for all active requests to complete before shutting down.

Each example waits up to 60 seconds for requests to complete before shutting down.

Graceful shutdown using an OS signal will not work if the JVM is configured to disable signal handling, such as when the -Xrs java argument is passed to the JVM options, or if the signal sent is not one the process can respond to, such as if a KILL signal is sent.

You can use a command to start an RPM installation of JBoss EAP in either standalone server or managed domain operating modes. Note that the following commands are only compatible with Red Hat Enterprise Linux (RHEL) 8 and later versions.

sudo systemctl start eap8-standalone.service

$ sudo systemctl start eap8-standalone.service

This will start JBoss EAP using the standalone.xml configuration file by default. You can start JBoss EAP with a different standalone server configuration file by setting a property in the RPM service configuration file. For more information, see the Configure RPM Service Properties section below.

sudo systemctl start eap8-domain.service

$ sudo systemctl start eap8-domain.service

This will start JBoss EAP using the host.xml configuration file by default. You can start JBoss EAP with a different managed domain configuration file by setting a property in the RPM service configuration file. For more information, see the Configure RPM Service Properties section below.

This section shows you how to configure the RPM service properties and other startup options for your JBoss EAP installation. Note that it is recommended to back up your configuration files before making modifications.

For a listing of all available startup options for an RPM installation, see the RPM Service Configuration Properties section.

You can use a command to stop an RPM installation of JBoss EAP in either standalone server or managed domain operating modes. Note that the following commands are only compatible with Red Hat Enterprise Linux (RHEL) 8 and later versions.

sudo systemctl stop eap8-standalone.service

$ sudo systemctl stop eap8-standalone.service

sudo systemctl stop eap8-domain.service

$ sudo systemctl stop eap8-domain.service

For a list of all available startup options for an RPM installation, see the RPM Service Configuration Files section.

You can use the add-user utility script to add a management user.

Users can also be created non-interactively by passing parameters to the add-user script. This approach is not recommended on shared systems, because the passwords will be visible in log and history files. For more information, see Running the add-user utility non-interactively.

You can run the add-user script non-interactively by passing in arguments on the command line. At a minimum, the username and password must be provided.

Create a user belonging to multiple groups

The following command adds a management user, mgmtuser1, with the guest and mgmtgroup groups.

EAP_HOME/bin/add-user.sh -u 'mgmtuser1' -p 'password1!' -g 'guest,mgmtgroup'

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser1' -p 'password1!' -g 'guest,mgmtgroup'

Specify an alternative properties file

By default, user and group information created using the add-user script are stored in properties files located in the server configuration directory.

User information is stored in the following properties files:

Group information is stored in the following properties files:

These default directories and properties file names can be overridden. The following command adds a new user, specifying a different name and location for the user properties files.

EAP_HOME/bin/add-user.sh -u 'mgmtuser2' -p 'password1!' -sc '/path/to/standaloneconfig/' -dc '/path/to/domainconfig/' -up 'newname.properties'

$ EAP_HOME/bin/add-user.sh -u 'mgmtuser2' -p 'password1!' -sc '/path/to/standaloneconfig/' -dc '/path/to/domainconfig/' -up 'newname.properties'

The new user was added to the user properties files located at /path/to/standaloneconfig/newname.properties and /path/to/domainconfig/newname.properties. Note that these files must already exist or you will see an error.

For a complete listing of all available add-user arguments and their purposes, use the --help argument or see the Add-user utility arguments section.

The password restrictions for the add-user utility script can be configured using the EAP_HOME/bin/add-user.properties file.

To avoid setting an unintentional password, check that your keyboard’s system keymap is correct. The default system keymap is en-qwerty. If you change this default setting and create a new password, you must check that the password meets the criteria located in the class SimplePasswordStrengthChecker.

By default, JBoss EAP allows weak passwords but issues a warning. To reject passwords that do not meet the minimum requirements specified, set the password.restriction property to REJECT.

The following table describes the additional password requirement settings that can be configured in the EAP_HOME/bin/add-user.properties file:

You can update the settings for an existing management user using the add-user utility script by entering the username when prompted.

EAP_HOME/bin/add-user.sh

$ EAP_HOME/bin/add-user.sh

What type of user do you wish to add?
 a) Management User (mgmt-users.properties)
 b) Application User (application-users.properties)
(a): a

Enter the details of the new user to add.
Using realm 'ManagementRealm' as discovered from the existing property files.
Username : test-user
User 'test-user' already exists and is enabled, would you like to...
 a) Update the existing user password and roles
 b) Disable the existing user
 c) Type a new username
(a):

When you enter a username that already exists, you are presented with several options:

The management command-line interface (CLI) is a command-line administration tool for JBoss EAP.

Use the management CLI to start and stop servers, deploy and undeploy applications, configure system settings, and perform other administrative tasks. Operations can be performed in batch mode, allowing multiple tasks to be run as a group.

Many common terminal commands are available, such as ls, cd, and pwd. The management CLI also supports tab completion.

For detailed information on using the management CLI, including commands and operations, syntax, and running in batch mode, see the JBoss EAP Management CLI Guide.

Launch the management CLI

EAP_HOME/bin/jboss-cli.sh

$ EAP_HOME/bin/jboss-cli.sh

Connect to a running server

connect

connect

Or you can launch the management CLI and connect in one step by using the EAP_HOME/bin/jboss-cli.sh --connect command.

Display help

Use the following command for general help.

help

help

Use the --help flag on a command to receive instructions on using that specific command. For instance, to receive information on using deploy, the following command is executed.

deploy --help

deploy --help

Quit the management CLI

quit

quit

View system settings

The following command uses the read-attribute operation to display whether the example datasource is enabled.

/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)
{
    "outcome" => "success",
    "result" => true
}

/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)
{
    "outcome" => "success",
    "result" => true
}

When running in a managed domain, you must specify which profile to update by preceding the command with /profile=PROFILE_NAME.

/profile=default/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)

/profile=default/subsystem=datasources/data-source=ExampleDS:read-attribute(name=enabled)

Update system settings

The following command uses the write-attribute operation to disable the example datasource.

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)

/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)

Start servers

The management CLI can also be used to start and stop servers when running in a managed domain.

/host=HOST_NAME/server=server-one:start

/host=HOST_NAME/server=server-one:start

The management console is a web-based administration tool for JBoss EAP.

Use the management console to start and stop servers, deploy and remove applications, tune system settings, and make persistent modifications to the server configuration. The management console can also perform administrative tasks, with live notifications when a user makes any changes that require you to restart or reload the server.

In a managed domain, server instances and server groups in the same domain are centrally managed from the management console of the domain controller.

For a JBoss EAP instance running on the local host using the default management port, you can access the management console through a web browser at http://localhost:9990/console/index.html. Log in as a user with the required role to access the management console.

The management console provides the following tabs for navigating and managing your JBoss EAP standalone server or managed domain.

/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=true)

/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=true)

/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=false)

/core-service=management/management-interface=http-interface:write-attribute(name=console-enabled,value=false)

The HTTP API endpoint is the entry point for management clients that rely on the HTTP protocol to integrate with the JBoss EAP management layer.

The HTTP API is used by the JBoss EAP management console but offers integration capabilities for other clients as well. By default, the HTTP API is accessible at http://HOST_NAME:9990/management. This URL will display the raw attributes and values exposed to the API.

Read resources

While you can read, write, or perform other operations using the HTTP POST method, you can perform some read operations using a GET request. The HTTP GET method uses the following URL format.

http://HOST_NAME:9990/management/PATH_TO_RESOURCE?operation=OPERATION&PARAMETER=VALUE

http://HOST_NAME:9990/management/PATH_TO_RESOURCE?operation=OPERATION&PARAMETER=VALUE

Be sure to replace all of the replaceable values with those that are appropriate for your request. The following values are the available options for the OPERATION replaceable value:

The following example URLs show how to perform read operations using the HTTP API.

http://HOST_NAME:9990/management/subsystem/undertow/server/default-server/http-listener/default

http://HOST_NAME:9990/management/subsystem/undertow/server/default-server/http-listener/default

This displays all attributes and their values for the default HTTP listener.

http://HOST_NAME:9990/management/subsystem/datasources/data-source/ExampleDS?operation=attribute&name=enabled

http://HOST_NAME:9990/management/subsystem/datasources/data-source/ExampleDS?operation=attribute&name=enabled

This reads the value of the enabled attribute for the ExampleDS datasource.

Update resources

You can use the HTTP POST method to update configuration values or perform other operations using the HTTP API. You must provide authentication for these operations.

The following examples show how to update resources using the HTTP API.

curl --digest http://HOST_NAME:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"write-attribute", "address":["subsystem","datasources","data-source","ExampleDS"], "name":"enabled", "value":"false", "json.pretty":"1"}'

$ curl --digest http://HOST_NAME:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"write-attribute", "address":["subsystem","datasources","data-source","ExampleDS"], "name":"enabled", "value":"false", "json.pretty":"1"}'

This updates the value of the enabled attribute for the ExampleDS datasource to false.

curl --digest http://localhost:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"reload"}'

$ curl --digest http://localhost:9990/management --header "Content-Type: application/json" -u USERNAME:PASSWORD -d '{"operation":"reload"}'

This reloads the server.

See Deploying Applications Using the HTTP API for information on how to deploy applications to JBoss EAP using the HTTP API.

The native API endpoint is the entry point for management clients that rely on the native protocol to integrate with the JBoss EAP management layer. The native API is used by the JBoss EAP management CLI but offers integration capabilities for other clients as well.

The following Java code shows an example of how to execute management operations from Java code using the native API.

// Create the management client
import org.jboss.dmr.ModelNode;
import org.jboss.as.controller.client.ModelControllerClient;
ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990);

// Create the operation request
ModelNode op = new ModelNode();

// Set the operation
op.get("operation").set("read-resource");

// Set the address
ModelNode address = op.get("address");
address.add("subsystem", "undertow");
address.add("server", "default-server");
address.add("http-listener", "default");

// Execute the operation and manipulate the result
ModelNode returnVal = client.execute(op);
System.out.println("Outcome: " + returnVal.get("outcome").toString());
System.out.println("Result: " + returnVal.get("result").toString());

// Close the client
client.close();

// Create the management client
import org.jboss.dmr.ModelNode;
import org.jboss.as.controller.client.ModelControllerClient;
ModelControllerClient client = ModelControllerClient.Factory.create("localhost", 9990);

// Create the operation request
ModelNode op = new ModelNode();

// Set the operation
op.get("operation").set("read-resource");

// Set the address
ModelNode address = op.get("address");
address.add("subsystem", "undertow");
address.add("server", "default-server");
address.add("http-listener", "default");

// Execute the operation and manipulate the result
ModelNode returnVal = client.execute(op);
System.out.println("Outcome: " + returnVal.get("outcome").toString());
System.out.println("Result: " + returnVal.get("result").toString());

// Close the client
client.close();

The standalone configuration files are located in the EAP_HOME/standalone/configuration/ directory. A separate file exists for each of the five predefined profiles (default, ha, full, full-ha, load-balancer). These are example configuration files that you can modify using the management CLI when you start JBoss EAP.

By default, starting JBoss EAP as a standalone server uses the standalone.xml file. To start JBoss EAP with a different configuration, use the --server-config argument. For example,

EAP_HOME/bin/standalone.sh --server-config=standalone-full.xml

$ EAP_HOME/bin/standalone.sh --server-config=standalone-full.xml

Update a standalone server using YAML files

Using YAML files to configure your standalone server externalizes the customization process and improves the rate of server upgrades. When using this feature, the server starts in read-only mode. This means that changes to the configuration do not persist after the server is restarted.

Users can modify various resources in the YAML files. The following elements are supported in YAML files:

The following elements are not supported in YAML files:

The YAML root node is wildfly-configuration. You can follow the model tree to modify resources. If a resource already exists (it was created by the XML configuration file or a previous YAML file), you can update it using the model tree. If the resource does not exist, you can create it using the model tree.

wildfly-configuration:
  subsystem:
    datasources:
      jdbc-driver:
        postgresql:
          driver-name: postgresql
          driver-xa-datasource-class-name: org.postgresql.xa.PGXADataSource
          driver-module-name: org.postgresql.jdbc
      data-source:
        PostgreSQLDS:
          enabled: true
          exception-sorter-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
          jndi-name: java:jboss/datasources/PostgreSQLDS
          jta: true
          max-pool-size: 20
          min-pool-size: 0
          connection-url: "jdbc:postgresql://localhost:5432}/demo"
          driver-name: postgresql
          user-name: postgres
          password: postgres
          validate-on-match: true
          background-validation: false
          background-validation-millis: 10000
          flush-strategy: FailingConnectionOnly
          statistics-enable: false
          stale-connection-checker-class-name: org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
          valid-connection-checker-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
          transaction-isolation: TRANSACTION_READ_COMMITTED

wildfly-configuration:
  subsystem:
    datasources:
      jdbc-driver:
        postgresql:
          driver-name: postgresql
          driver-xa-datasource-class-name: org.postgresql.xa.PGXADataSource
          driver-module-name: org.postgresql.jdbc
      data-source:
        PostgreSQLDS:
          enabled: true
          exception-sorter-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
          jndi-name: java:jboss/datasources/PostgreSQLDS
          jta: true
          max-pool-size: 20
          min-pool-size: 0
          connection-url: "jdbc:postgresql://localhost:5432}/demo"
          driver-name: postgresql
          user-name: postgres
          password: postgres
          validate-on-match: true
          background-validation: false
          background-validation-millis: 10000
          flush-strategy: FailingConnectionOnly
          statistics-enable: false
          stale-connection-checker-class-name: org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
          valid-connection-checker-class-name: org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
          transaction-isolation: TRANSACTION_READ_COMMITTED

The above example defines a jdbc-driver called postgresql and a data-source called PostgreSQLDS.

The managed domain configuration files are located in the EAP_HOME/domain/configuration/ directory. These are example configuration files that you can modify using the management CLI when you start JBoss EAP.

By default, starting JBoss EAP in a managed domain uses the host.xml file. To start JBoss EAP with a different configuration, use the --host-config argument. For example,

EAP_HOME/bin/domain.sh --host-config=host-primary.xml

$ EAP_HOME/bin/domain.sh --host-config=host-primary.xml

To restore your JBoss EAP server configuration, you must back up your data in the following locations:

To assist in the maintenance and management of the server, JBoss EAP creates a timestamped version of the original configuration file at the time of startup.

Any additional configuration changes made by management operations will result in the original file being automatically backed up, and a working copy of the instance being preserved for reference and rollback. Additionally, configuration snapshots can be taken, which are point-in-time copies of the current server configuration. These snapshots can be saved and loaded by an administrator.

The following examples use the standalone.xml file, but the same process applies to the domain.xml and host.xml files.

Take a snapshot

Use the management CLI to take a snapshot of the current configurations.

:take-snapshot
{
    "outcome" => "success",
    "result" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20151022-133109702standalone.xml"
}

:take-snapshot
{
    "outcome" => "success",
    "result" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20151022-133109702standalone.xml"
}

List snapshots

Use the management CLI to list all snapshots.

:list-snapshots
{
    "outcome" => "success",
    "result" => {
        "directory" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
        "names" => [
            "20151022-133109702standalone.xml",
            "20151022-132715958standalone.xml"
        ]
    }
}

:list-snapshots
{
    "outcome" => "success",
    "result" => {
        "directory" => "EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
        "names" => [
            "20151022-133109702standalone.xml",
            "20151022-132715958standalone.xml"
        ]
    }
}

Delete a snapshot

Use the management CLI to delete a snapshot.

:delete-snapshot(name=20151022-133109702standalone.xml)

:delete-snapshot(name=20151022-133109702standalone.xml)

You can start a server using a snapshot or an automatically-saved version of the configuration.

You can use JBoss EAP to track configuration changes made to the running system. This allows administrators to view a history of configuration changes made by other authorized users.

You can enable tracking and view configuration changes from either the management CLI or the management console.

Track and view configuration changes from the management CLI

To enable tracking of configuration changes, use the following management CLI command. You can specify how many entries to store using the max-history attribute.

/subsystem=core-management/service=configuration-changes:add(max-history=20)

/subsystem=core-management/service=configuration-changes:add(max-history=20)

/host=HOST_NAME/subsystem=core-management/service=configuration-changes:add(max-history=20)

/host=HOST_NAME/subsystem=core-management/service=configuration-changes:add(max-history=20)

To view the list of most recent configuration changes, use the following management CLI command.

/subsystem=core-management/service=configuration-changes:list-changes

/subsystem=core-management/service=configuration-changes:list-changes

/host=HOST_NAME/subsystem=core-management/service=configuration-changes:list-changes

/host=HOST_NAME/subsystem=core-management/service=configuration-changes:list-changes

/host=HOST_NAME/server=SERVER_NAME/subsystem=core-management/service=configuration-changes:list-changes

/host=HOST_NAME/server=SERVER_NAME/subsystem=core-management/service=configuration-changes:list-changes

This lists each configuration change made, with the date, origin, outcome, and operation details. For example, the below output from the list-changes command shows configuration changes, with the most recent displayed first.

{
    "outcome" => "success",
    "result" => [
        {
            "operation-date" => "2016-02-12T18:37:00.354Z",
            "access-mechanism" => "NATIVE",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "address" => [],
                "operation" => "reload",
                "operation-headers" => {
                    "caller-type" => "user",
                    "access-mechanism" => "NATIVE"
                }
            }]
        },
        {
            "operation-date" => "2016-02-12T18:34:16.859Z",
            "access-mechanism" => "NATIVE",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "address" => [
                    ("subsystem" => "datasources"),
                    ("data-source" => "ExampleDS")
                ],
                "operation" => "write-attribute",
                "name" => "enabled",
                "value" => false,
                "operation-headers" => {
                    "caller-type" => "user",
                    "access-mechanism" => "NATIVE"
                }
            }]
        },
        {
            "operation-date" => "2016-02-12T18:24:11.670Z",
            "access-mechanism" => "HTTP",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "operation" => "remove",
                "address" => [
                    ("subsystem" => "messaging-activemq"),
                    ("server" => "default"),
                    ("jms-queue" => "ExpiryQueue")
                ],
                "operation-headers" => {"access-mechanism" => "HTTP"}
            }]
        }
    ]
}

{
    "outcome" => "success",
    "result" => [
        {
            "operation-date" => "2016-02-12T18:37:00.354Z",
            "access-mechanism" => "NATIVE",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "address" => [],
                "operation" => "reload",
                "operation-headers" => {
                    "caller-type" => "user",
                    "access-mechanism" => "NATIVE"
                }
            }]
        },
        {
            "operation-date" => "2016-02-12T18:34:16.859Z",
            "access-mechanism" => "NATIVE",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "address" => [
                    ("subsystem" => "datasources"),
                    ("data-source" => "ExampleDS")
                ],
                "operation" => "write-attribute",
                "name" => "enabled",
                "value" => false,
                "operation-headers" => {
                    "caller-type" => "user",
                    "access-mechanism" => "NATIVE"
                }
            }]
        },
        {
            "operation-date" => "2016-02-12T18:24:11.670Z",
            "access-mechanism" => "HTTP",
            "remote-address" => "127.0.0.1/127.0.0.1",
            "outcome" => "success",
            "operations" => [{
                "operation" => "remove",
                "address" => [
                    ("subsystem" => "messaging-activemq"),
                    ("server" => "default"),
                    ("jms-queue" => "ExpiryQueue")
                ],
                "operation-headers" => {"access-mechanism" => "HTTP"}
            }]
        }
    ]
}

This example lists the details of three operations performed that impacted the configuration:

Track and view configuration changes from the management console

To enable tracking of configuration changes from the management console, select to the Runtime tab, navigate to the server or host to track changes for and select Configuration Changes from the drop down. Click Enable Configuration Changes and provide a maximum history value.

The table on this page then lists each configuration change made, with the date, origin, outcome, and operation details.

You can use expressions in JBoss EAP to define replaceable properties in place of literal values in the configuration.

Using property replacement in standalone*.xml or domain.xml configuration files will replace the property with the value found in a system property. System properties are defined in the EAP profile xml file or by typing -D command from the command line terminal.

To determine if property replacement is allowed in a given subsystem, use the following command to display a description of a subsystem configuration:

/subsystem=datasources:read-resource-description(recursive=true)

/subsystem=datasources:read-resource-description(recursive=true)

If the expressions-allowed attribute is set to true, property replacement is allowed.

Expressions use the format ${PARAMETER:DEFAULT_VALUE}. If the specified parameter is set, then the parameter’s value will be used. Otherwise, the default value provided will be used.

The supported sources for resolving expressions are system properties and environment variables. When resolving expressions using environment variables, use the format ${env.LANG}.

The following example from the standalone.xml configuration file sets the inet-address for the public interface to 127.0.0.1 unless the jboss.bind.address parameter is set.

<interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>

<interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
</interface>

You can use the following command to set the jboss.bind.address parameter when starting EAP as a standalone server:

EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

You can nest expressions, which allows for more advanced use of expressions in place of fixed values.

The format of a nested expression is like that of a normal expression, but one expression is embedded in the other, for example:

${SYSTEM_VALUE_1${SYSTEM_VALUE_2}}

${SYSTEM_VALUE_1${SYSTEM_VALUE_2}}

JBoss EAP evaluates nested expressions recursively, so the inner expression is first evaluated, then the outer expression is evaluated. Expressions can also be recursive, where an expression resolves to another expression, which is then resolved. Nested expressions are permitted anywhere that expressions are permitted, with the exception of management CLI commands.

You might use a nested expression if a datasource definition password is masked, for example.

Deployment descriptor-based property replacement substitutes properties based on descriptors, so that you can remove assumptions about the environment from the application and the build chain.

Environment-specific configurations can be specified in deployment descriptors rather than annotations or build system scripts. You can provide configuration in files or as parameters at the command line.

Application configuration, such as datasource connection parameters, typically varies between development, testing, and production environments. This variance is sometimes accommodated by build system scripts, as the Jakarta EE specification does not contain a method to externalize these configurations. With JBoss EAP, you can use descriptor-based property replacement to manage configuration externally.

The spec-descriptor-property-replacement flag controls Jakarta EE descriptor replacement, and JBoss EAP disables it by default. When it’s enabled, you can replace properties in the following deployment descriptors:

You can use the following management CLI command to enable or disable property replacement in Jakarta EE descriptors:

/subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)

/subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)

The jboss-descriptor-property-replacement flag controls JBoss-specific descriptor replacement, and JBoss EAP enables it by default. When it’s enabled, you can replace properties in the following deployment descriptors:

Use the following management CLI command to enable or disable property replacement in JBoss EAP-specific descriptors:

/subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

/subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

The annotation-property-replacement flag controls property replacement inside of annotations, and it is not enabled by default. When it’s enabled, you can replace properties in the annotation attributes inside of application classes.

Use the following management CLI command to enable or disable property replacement in annotations:

/subsystem=ee:write-attribute(name="annotation-property-replacement",value=VALUE)

/subsystem=ee:write-attribute(name="annotation-property-replacement",value=VALUE)

You can set annotation-property-replacement to true to enable property replacement in your annotations when a system property value is set. For example, you can set a system property to replace the maxSession value on a Message Driven Bean:

@MessageDriven(mappedName="jms/Queue", activationConfig =  {
        @ActivationConfigProperty(propertyName = "acknowledgeMode",
                                  propertyValue = "Auto-acknowledge"),
        @ActivationConfigProperty(propertyName = "destinationType",
                                  propertyValue = "javax.jms.Queue")
@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "${exampleMDB.maxSession:20}")})
    })
public class ExampleMessageDrivenBean implements MessageListener {
...
}

@MessageDriven(mappedName="jms/Queue", activationConfig =  {
        @ActivationConfigProperty(propertyName = "acknowledgeMode",
                                  propertyValue = "Auto-acknowledge"),
        @ActivationConfigProperty(propertyName = "destinationType",
                                  propertyValue = "javax.jms.Queue")
@ActivationConfigProperty(propertyName = "maxSession", propertyValue = "${exampleMDB.maxSession:20}")})
    })
public class ExampleMessageDrivenBean implements MessageListener {
...
}

You could set -DexampleMDB.maxSession system property to 100. If this system property is not set, the value will default to 20.

You can use Git to manage and persist your server configuration data, properties files, and deployments. This not only allows you to manage the version history for these files, but it also allows you to share server and application configurations across multiple servers and nodes using one or more Git repositories. This feature only works for standalone servers that use the default configuration directory layout.

You can choose to use configuration data in a local Git repository or you can pull the data from a remote Git repository. The Git repository is configured in the jboss.server.base.dir directory, which is the base directory for standalone server content. Once the jboss.server.base.dir directory is configured to use Git, JBoss EAP automatically commits every update you make to the configuration using the management CLI or management console. Any changes made outside of the server by manually editing the configuration files are not committed or persisted; however, you can use the Git CLI to add and commit manual changes. You can also use the Git CLI to view the commit history, manage branching, and manage the content.

To use this feature, pass one or more of the following arguments on the command line when you start the server.

Using a local Git repository

To use a local Git repository, start the server with the --git-repo=local argument. You can also specify an optional branch or tag name in the remote repository by adding the --git-branch=GIT_BRANCH_NAME argument when you start the server. This argument should name an existing branch or tag name as it will not be created if it does not exist. If you use a tag name, you put the repository in a detached HEAD state, meaning future commits are not attached to any branches.

The following is an example of a command to start the server using the 1.0.x branch of the local repository.

EAP_HOME/bin/standalone.sh --git-repo=local --git-branch=1.0.x

$ EAP_HOME/bin/standalone.sh --git-repo=local --git-branch=1.0.x

If you start the server with the argument to use a local Git repository, JBoss EAP checks whether the jboss.server.base.dir directory is already configured for Git. If not, JBoss EAP creates and initializes the Git repository in the jboss.server.base.dir directory using the existing configuration content. JBoss EAP checks out a branch name passed by the --git-branch argument. If that argument is not passed, it checks out the master branch. After initialization, you should see a .git/ directory and a .gitignore file in the base directory for standalone server content.

Using a remote Git repository

To use a remote Git repository, start the server with the --git-repo=REMOTE_REPO argument. The value of the argument can be a URL or a remote alias that you have manually added to the local Git configuration.

You can also specify an optional branch or tag name in the remote repository by adding the --git-branch=GIT_BRANCH_NAME argument when you start the server. This argument should name an existing branch or tag name as it will not be created if it does not exist. If you use a tag name, you put the repository in a detached HEAD state, meaning future commits are not attached to any branches.

If your Git repository requires authentication, you must also add the --git-auth=AUTH_FILE_URL argument when you start the server. This argument should be the URL to an Elytron configuration file containing the credentials required to connect to the Git repository. The following is an example of a WildFly Client configuration file specifying an Elytron configuration that can be used for authentication.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <authentication-client xmlns="{ElytronAuthClientNamespace}">
    <authentication-rules>
      <rule use-configuration="test-login">
      </rule>
    </authentication-rules>
    <authentication-configurations>
      <configuration name="test-login">
        <sasl-mechanism-selector selector="BASIC" />
        <set-user-name name="eap-user" />
        <credentials>
          <clear-password password="my_api_key" />
        </credentials>
        <set-mechanism-realm name="testRealm" />
      </configuration>
    </authentication-configurations>
  </authentication-client>
</configuration>

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <authentication-client xmlns="{ElytronAuthClientNamespace}">
    <authentication-rules>
      <rule use-configuration="test-login">
      </rule>
    </authentication-rules>
    <authentication-configurations>
      <configuration name="test-login">
        <sasl-mechanism-selector selector="BASIC" />
        <set-user-name name="eap-user" />
        <credentials>
          <clear-password password="my_api_key" />
        </credentials>
        <set-mechanism-realm name="testRealm" />
      </configuration>
    </authentication-configurations>
  </authentication-client>
</configuration>

The following is an example of a command to start the server with the full profile, using the 1.0.x branch of the remote eap-configuration repository, and passing the URL to an Elytron configuration file containing authentication credentials.

EAP_HOME/bin/standalone.sh --git-repo=https://github.com/MY_GIT_ID/eap-configuration.git --git-branch=1.0.x --git-auth=file:///home/USER_NAME/github-wildfly-config.xml --server-config=standalone-full.xml

$ EAP_HOME/bin/standalone.sh --git-repo=https://github.com/MY_GIT_ID/eap-configuration.git --git-branch=1.0.x --git-auth=file:///home/USER_NAME/github-wildfly-config.xml --server-config=standalone-full.xml

If you start the server with the argument to use a remote Git repository, JBoss EAP checks whether the jboss.server.base.dir directory is already configured for Git. If not, JBoss EAP deletes the existing configuration files in the jboss.server.base.dir directory and replaces them with the remote Git configuration data. JBoss EAP checks out a branch name passed by the --git-branch argument. If that argument is not passed, it checks out the master branch. Once this process is complete, you should see a .git/ directory and a .gitignore file in the base directory for standalone server content.

Publishing remote configuration data when using Git

You can push your Git repository changes to the remote repository using the management CLI publish-configuration operation. Because JBoss EAP pulls the configuration from the remote Git repository during the boot process when you start the server, this allows you to share the configuration data across multiple servers. You can only use this operation with a remote repository. It does not work for a local repository.

The following management CLI operation publishes the configuration data to the remote eap-configuration repository.

:publish-configuration(location="=https://github.com/MY_GIT_ID/eap-configuration.git")
{"outcome" => "success"}

:publish-configuration(location="=https://github.com/MY_GIT_ID/eap-configuration.git")
{"outcome" => "success"}

Using snapshots with Git

In addition to using the Git commit history to track configuration changes, you can also take snapshots to preserve a configuration at a specific point in time. You can list the snapshots and delete them.

Taking snapshots when using Git

Snapshots are stored as tags in Git. You specify the snapshot tag name and commit message as arguments on the take-snapshot operation.

The following management CLI operation takes a snapshot and names the tag "snapshot-01".

:take-snapshot(name="snapshot-01", comment="1st snapshot")
{
    "outcome" => "success",
    "result" => "1st snapshot"
}

:take-snapshot(name="snapshot-01", comment="1st snapshot")
{
    "outcome" => "success",
    "result" => "1st snapshot"
}

Listing snapshots When using Git

You can list all of the snapshot tags using the list-snapshots operation.

The following management CLI operation lists the snapshot tags.

:list-snapshots
{
    "outcome" => "success",
    "result" => {
        "directory" => "",
        "names" => [
            "snapshot : 1st snapshot",
            "refs/tags/snapshot-01",
            "snapshot2 : 2nd snapshot",
            "refs/tags/snapshot-02"
        ]
    }
}

:list-snapshots
{
    "outcome" => "success",
    "result" => {
        "directory" => "",
        "names" => [
            "snapshot : 1st snapshot",
            "refs/tags/snapshot-01",
            "snapshot2 : 2nd snapshot",
            "refs/tags/snapshot-02"
        ]
    }
}

Deleting snapshots when using Git

You can delete a specific snapshot by passing the tag name on the delete-snapshot operation.

The following management CLI operation deletes the snapshot with the tag name "snapshot-01".

:delete-snapshot(name="snapshot-01")
{"outcome" => "success"}

:delete-snapshot(name="snapshot-01")
{"outcome" => "success"}

Use the following management CLI command to list the file system paths:

ls /path

ls /path

ls /host=HOST_NAME/server=SERVER_NAME/path

ls /host=HOST_NAME/server=SERVER_NAME/path

Use the following management CLI command to read the value of a file system path:

/path=PATH_NAME:read-resource

/path=PATH_NAME:read-resource

/host=HOST_NAME/server=SERVER_NAME/path=PATH_NAME:read-resource

/host=HOST_NAME/server=SERVER_NAME/path=PATH_NAME:read-resource

You can override the default locations of the standard paths that begin with jboss.server.* or jboss.domain.*. This can be done in one of two ways:

Overriding standard paths in a managed domain

In this example, the objective is to store domain files in the /opt/jboss_eap/domain_data directory, and give each top-level directory a custom name. The default directory grouping, by-server, is used.

To achieve this configuration, you would override several system properties when starting JBoss EAP.

EAP_HOME/bin/domain.sh -Djboss.domain.temp.dir=/opt/jboss_eap/domain_data/all_temp -Djboss.domain.log.dir=/opt/jboss_eap/domain_data/all_logs -Djboss.domain.data.dir=/opt/jboss_eap/domain_data/all_data -Djboss.domain.servers.dir=/opt/jboss_eap/domain_data/all_servers

$ EAP_HOME/bin/domain.sh -Djboss.domain.temp.dir=/opt/jboss_eap/domain_data/all_temp -Djboss.domain.log.dir=/opt/jboss_eap/domain_data/all_logs -Djboss.domain.data.dir=/opt/jboss_eap/domain_data/all_data -Djboss.domain.servers.dir=/opt/jboss_eap/domain_data/all_servers

The resulting path structure will be as follows:

/opt/jboss_eap/domain_data/
               ├── all_data
               ├── all_logs
               ├── all_servers
               │   ├── server-one
               │   │   ├── data
               │   │   ├── log
               │   │   └── tmp
               │   └── server-two
               │       ├── data
               │       ├── log
               │       └── tmp
               └── all_temp

/opt/jboss_eap/domain_data/
               ├── all_data
               ├── all_logs
               ├── all_servers
               │   ├── server-one
               │   │   ├── data
               │   │   ├── log
               │   │   └── tmp
               │   └── server-two
               │       ├── data
               │       ├── log
               │       └── tmp
               └── all_temp

You can add a custom file system path using the management CLI or the management console.

You can then use this custom path in your configuration. For example, the below log handler uses a custom path for its relative path.

<subsystem xmlns="{LoggingSubsystemNamespace}">
  ...
  <periodic-rotating-file-handler name="FILE" autoflush="true">
    <formatter>
      <named-formatter name="PATTERN"/>
    </formatter>
    <file relative-to="my.custom.path" path="server.log"/>
    <suffix value=".yyyy-MM-dd"/>
    <append value="true"/>
  </periodic-rotating-file-handler>
  ...
</subsystem>

<subsystem xmlns="{LoggingSubsystemNamespace}">
  ...
  <periodic-rotating-file-handler name="FILE" autoflush="true">
    <formatter>
      <named-formatter name="PATTERN"/>
    </formatter>
    <file relative-to="my.custom.path" path="server.log"/>
    <suffix value=".yyyy-MM-dd"/>
    <append value="true"/>
  </periodic-rotating-file-handler>
  ...
</subsystem>

Though disabled by default, the default audit logging configuration writes to a file.

<audit-log>
    <formatters>
        <json-formatter name="json-formatter"/>
    </formatters>
    <handlers>
        <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
    </handlers>
    <logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="file"/>
        </handlers>
    </logger>
</audit-log>

<audit-log>
    <formatters>
        <json-formatter name="json-formatter"/>
    </formatters>
    <handlers>
        <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
    </handlers>
    <logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="file"/>
        </handlers>
    </logger>
</audit-log>

This configuration can be read using the following management CLI command.

/core-service=management/access=audit:read-resource(recursive=true)

/core-service=management/access=audit:read-resource(recursive=true)

See Enable audit logging to enable audit logging for a standalone server.

Though disabled by default, the default audit logging configuration writes a file for each host and for each server.

<audit-log>
    <formatters>
        <json-formatter name="json-formatter"/>
    </formatters>
    <handlers>
        <file-handler name="host-file" formatter="json-formatter" relative-to="jboss.domain.data.dir" path="audit-log.log"/>
        <file-handler name="server-file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
    </handlers>
    <logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="host-file"/>
        </handlers>
    </logger>
    <server-logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="server-file"/>
        </handlers>
    </server-logger>
</audit-log>

<audit-log>
    <formatters>
        <json-formatter name="json-formatter"/>
    </formatters>
    <handlers>
        <file-handler name="host-file" formatter="json-formatter" relative-to="jboss.domain.data.dir" path="audit-log.log"/>
        <file-handler name="server-file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
    </handlers>
    <logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="host-file"/>
        </handlers>
    </logger>
    <server-logger log-boot="true" log-read-only="false" enabled="false">
        <handlers>
            <handler name="server-file"/>
        </handlers>
    </server-logger>
</audit-log>

This configuration can be read using the following management CLI command.

/host=HOST_NAME/core-service=management/access=audit:read-resource(recursive=true)

/host=HOST_NAME/core-service=management/access=audit:read-resource(recursive=true)

See Enable Audit Logging to enable audit logging for a managed domain.

JBoss EAP is preconfigured with file handlers for audit logging, though audit logging is disabled by default. The management CLI command to enable audit logging depends on whether you are running as a standalone server or in a managed domain. See Management audit logging attributes for file handler attributes.

The following instructions enable NATIVE and HTTP audit logging. To configure JMX audit logging, see Enable JMX management audit logging.

To set up syslog audit logging, see Send management audit logging to a syslog server.

/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

/host=HOST_NAME/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

/host=HOST_NAME/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)

/host=HOST_NAME/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)

/host=HOST_NAME/core-service=management/access=audit/server-logger=audit-log:write-attribute(name=enabled,value=true)

JBoss EAP is preconfigured with file handlers for JMX audit logging, though these logs are disabled by default. The management CLI command to enable audit logging depends on whether you are running as a standalone server or a managed domain.

To configure NATIVE or HTTP audit logging, see Enable management audit logging.

/subsystem=jmx/configuration=audit-log:add()
/subsystem=jmx/configuration=audit-log/handler=file:add()

/subsystem=jmx/configuration=audit-log:add()
/subsystem=jmx/configuration=audit-log/handler=file:add()

A syslog handler specifies the parameters by which audit log entries are sent to a syslog server, specifically the syslog server’s host name and the port on which the syslog server is listening. Sending audit logging to a syslog server provides more security options than logging to a local file or local syslog server. Multiple syslog handlers can be defined and be active at the same time.

By default, audit logging is preconfigured to output to a file when enabled. Use the following steps to set up and enable audit logging to a syslog server. See Management Audit Logging Attributes for syslog handler attributes.

Audit log entries output to files are best viewed with a text viewer, while those output to a syslog server are best viewed using a syslog viewer application.

The audit log entries are stored in JSON format. Each log entry begins with an optional timestamp, followed by the fields in the below table.

You can register a listener to the JBoss EAP core-management subsystem to monitor for server lifecycle events. The following steps show how to create and register an example listener that logs the events to a file.

Now, server lifecycle events will be logged to the my-listener-output.txt file based on the SimpleListener class above. For example, issuing a :suspend command in the management CLI will output the following to the my-listener-output.txt file.

Running state change for STANDALONE_SERVER: normal to suspending
Running state change for STANDALONE_SERVER: suspending to suspended

Running state change for STANDALONE_SERVER: normal to suspending
Running state change for STANDALONE_SERVER: suspending to suspended

This shows that the running state changed from normal to suspending, and then from suspending to suspended.

You can register a JMX notification listener to monitor for server lifecycle events. The following steps show how to create and add an example listener that logs events to a file.

Server lifecycle events are now logged to a file based on the StateNotificationListener class above. For example, issuing a :suspend command in the management CLI outputs the following to the running-notifications.txt file.

jmx.attribute.change 5 jboss.root:type=state The attribute 'RunningState' has changed from 'normal' to 'suspending'
jmx.attribute.change 6 jboss.root:type=state The attribute 'RunningState' has changed from 'suspending' to 'suspended'

jmx.attribute.change 5 jboss.root:type=state The attribute 'RunningState' has changed from 'normal' to 'suspending'
jmx.attribute.change 6 jboss.root:type=state The attribute 'RunningState' has changed from 'suspending' to 'suspended'

This shows that the running state changed from normal to suspending, and then from suspending to suspended.

The following interface configurations are set by default:

<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
  <interface name="private">
    <inet-address value="${jboss.bind.address.private:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>

<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
  <interface name="private">
    <inet-address value="${jboss.bind.address.private:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>

JBoss EAP binds these interfaces to 127.0.0.1, but these values can be overridden at runtime by setting the appropriate property. For example, the inet-address of the public interface can be set when starting JBoss EAP as a standalone server with the following command.

EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

$ EAP_HOME/bin/standalone.sh -Djboss.bind.address=IP_ADDRESS

Alternatively, you can use the -b switch on the server start command line.

EAP_HOME/bin/standalone.sh -b IP_ADDRESS

$ EAP_HOME/bin/standalone.sh -b IP_ADDRESS

In the above command, -b IP_ADDRESS is equivalent to -Djboss.bind.address=IP_ADDRESS.

You can also use the -b switch to set the inet-address of the management interface.

EAP_HOME/bin/standalone.sh -bmanagement=IP_ADDRESS

$ EAP_HOME/bin/standalone.sh -bmanagement=IP_ADDRESS

If you only want to set a single variable, you can change jboss.bind.address.management to jboss.bind.address. When you set -b switch or -Djboss.bind.address, the public and management interfaces will share the same IP_ADDRESS.

For more information about server start options, see Server Runtime Arguments.

Network interfaces are declared by specifying a logical name and selection criteria for the physical interface. The selection criteria can reference a wildcard address or specify a set of one or more characteristics that an interface or address must have in order to be a valid match. For a listing of all available interface selection criteria, see the Interface Attributes section.

Interfaces can be configured using the management console or the management CLI. Below are several examples of adding and updating interfaces. The management CLI command is shown first, followed by the corresponding configuration XML.

Add an interface with a NIC value

Add a new interface with a NIC value of eth0.

/interface=external:add(nic=eth0)

/interface=external:add(nic=eth0)

<interface name="external">
   <nic name="eth0"/>
</interface>

<interface name="external">
   <nic name="eth0"/>
</interface>

Add an interface with several conditional values

Add a new interface that matches any interface/address on the correct subnet if it is up, supports multicast, and is not point-to-point.

/interface=default:add(subnet-match=192.168.0.0/16,up=true,multicast=true,not={point-to-point=true})

/interface=default:add(subnet-match=192.168.0.0/16,up=true,multicast=true,not={point-to-point=true})

<interface name="default">
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>

<interface name="default">
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>

Update an interface attribute

Update the public interface’s default inet-address value, keeping the jboss.bind.address property to allow for this value to be set at runtime.

/interface=public:write-attribute(name=inet-address,value="${jboss.bind.address:192.168.0.0}")

/interface=public:write-attribute(name=inet-address,value="${jboss.bind.address:192.168.0.0}")

<interface name="public">
    <inet-address value="${jboss.bind.address:192.168.0.0}"/>
</interface>

<interface name="public">
    <inet-address value="${jboss.bind.address:192.168.0.0}"/>
</interface>

Add an interface to a server in a managed domain

/host=HOST_NAME/server-config=SERVER_NAME/interface=INTERFACE_NAME:add(inet-address=127.0.0.1)

/host=HOST_NAME/server-config=SERVER_NAME/interface=INTERFACE_NAME:add(inet-address=127.0.0.1)

<servers>
   <server name="SERVER_NAME" group="main-server-group">
      <interfaces>
         <interface name="INTERFACE_NAME">
            <inet-address value="127.0.0.1"/>
         </interface>
      </interfaces>
   </server>
</servers>

<servers>
   <server name="SERVER_NAME" group="main-server-group">
      <interfaces>
         <interface name="INTERFACE_NAME">
            <inet-address value="127.0.0.1"/>
         </interface>
      </interfaces>
   </server>
</servers>